Cyril Brulebois: D-I Wheezy Alpha1
Get it while it s hot:
Debian Installer 7.0 Alpha1 release.
See how yummy it is:
xserver-xorg-input-synaptics
rc4
upload solved a lot
of issues, but the 1.6.0
release (just uploaded) should fix some
more. Enjoy!xorg-server
, merging from upstream
server-1.12-branch
to get many XI2.2 bug fixes, along with an
infinite loop bug fix (also seen with synaptics
).ia64
due to the recent changes,
so we requested they be removed,
which happened promptly!apt-get dist-upgrade
blindly without having to
fear the consequences.
Pro tip: when you see something like xserver-xorg
go away
during a dist-upgrade
, think twice before confirming!xf86-input-mtrack
was recently
fixed; xf86-video-glamo
and
xf86-video-msm
fail to build
(#671028,
#671806), so they stay
uninstallable for now. Thankfully nothing appears to depend on
them, so they can be temporarily removed from testing
if needs
be.experimental
first,
until the new server and its drivers make it into testing
.fglrx
still
doesn t support X server 1.12 (LOL!). The
other, big fat blobby driver is installable, and supposed to work.x11-apps
, x11-utils
, etc.), preparing for
the upcoming 7.7 katamari.experimental
, where it seems to
be building fine, and working fine, at least for me.unstable
very soon, and I
won t be disabling wayland support this time, since wayland/weston
reached their first milestone with a public release (0.85). There s
nothing very interesting to see here, but since wayland support
doesn t really hurt, I thought I d just keep it. That s why wayland
hit unstable
yesterday; weston
should follow after mesa
. (In
case somebody is in a hurry, they have been in experimental
for
quite some time already.)synaptics
driver seem to be finally fixed
thanks to rc4
: #665004 was
confirmed as fixed by many reporters (thanks everyone for the quick feedback
after my ping).
Accordingly, I ve pinged the release team to get an age-days 3
to
make it migrate faster, and a kind RM added that hint to his file, so
testing
is getting the fixed package thanks to this midnight s
britney
run.experimental
for a while, from
release candidates to the first stable release from
server-1.12-branch
. Since a bunch of drivers were uploaded to cope
with that version when it shows up, we should be able to upload
xorg-server
1.12 to unstable
VERY SOON.
What does that mean?
Basically, that s a transition. In details:
xorg-server
, and wait for it to be built everywhere,
then we trigger binNMUs for all architectures at once when it s
ready on all of them.input
and video
ABI). That
means that drivers won t be installable until they are rebuilt
against the new server. Usually, we re talking about a few
dinstall
runs, meaning less than a day.unstable
, and you
probably know installability-related issues are trivially solved
by pulling packages from testing
when needed. This is such a
case.$ zgrep foo
~/ftp://cdn.debian.net/debian/dists/sid/main/Contents-*.gz
On my Hurd box, the ~/ftp: directory is indeed actually served by an ftpfs
translator, run under my user uid, which is thus completely harmless to the
system.
Secondly and not the least, the Hurd provides me with interesting yet not too
hard challenges. LWN confirmed several times that the Linux kernel has become
very difficult to significantly contribute to, so it is no real hacking fun
any more. I have notably implemented TLS support in the Hurd and the Xen
and 64bit support in the GNU Mach kernel used by the Hurd. All three were
very interesting to do, but were already done for Linux (at least for all the
architectures which I actually know a bit and own). It happens that both TLS
and Xen hacking experience became actually useful later on: I implemented TLS
in the threading library of our research team, and the Xen port was a quite
interesting line on my CV for getting a postdoc position at XenSource
Lastly, I would say that I am used to lost causes My work on accessibility
is sometimes a real struggle, so the Hurd is almost a kind of relief. It is
famous for his vapourware reputation anyway, and so it is fun to just try to contribute
to it nevertheless. An interesting thing is that the opinion of people on the Hurd is
often quite extreme, and only rarely neutral. Some will say it is pure
vapourware, while others will say that it is the hope of humanity (yes we do see
those coming to #hurd, and they are not always just trolls!). When I published
a 0.401 version
on 2011 April 1st, the comments of people were very diverse, and some even
went as far as saying that it was horrible of us to make a joke about the
promised software
Raphael: The FTPmasters want to demote the Hurd port to the debian-ports.org
archive if it doesn t manage a stable release with wheezy. We re now at 2 months
of the freeze. How far are you from being releasable ?
Samuel: Of course, I can not speak for the Debian Release team. The current
progress is however encouraging. During Debconf11, Michael Banck and I discussed with a
few Debian Release team members about the kind of goals that should be achieved,
and we are near completion of
that part. The Debian GNU/Hurd port can almost completely be installed from
the official mirrors, using the standard Debian
Installer. Some patches need some polishing, but others are just waiting for being uploaded
Debian GNU/Hurd can start a graphical desktop and run office tools such as
gnumeric, as well as the iceweasel graphical web browser, KDE applications
thanks to Pino Toscano s care, and GNOME application thanks to Emilio Pozuelo
Monfort s care. Of course, general
textmode hacking with gcc/make/gdb/etc. just works smoothly. Thanks to recent
work on ghc and ada by Svante Signell, the archive coverage has passed 76%.
There was a concern about network board driver support: until recently, the GNU
Mach kernel was indeed still using a glue layer to embed the Linux 2.2 or even
2.0 drivers (!). Finding a network board supported by such drivers had of course
become a real challenge. Thanks to the GSoC work of Zheng Da, the DDE layer
can now be used to embed Linux 2.6.32 drivers in userland translators, which
was recently ACCEPTed into the archive, and thus brings way larger support for
network boards. It also pushes yet more toward the Hurd design: network drivers
as userland process rather than kernel modules.
That said, the freeze itself is not the final deadline. Actually, freeze
periods are rests for porters, because maintainers stop bringing newer upstream
versions which of course break on peculiar architectures. That will probably be
helpful to continue improving the archive coverage.
Raphael: The kfreebsd port brought into light all the packages which were not
portable between different kernels. Did that help the Hurd port or are the problems
too different to expect any mutual benefit?
Samuel: The two ports have clearly helped each other in many aspects. The
hurd-i386 port is the only non-Linux one that has been kept working (at least
basically) for the past decade. That helped to make sure that all tools
(dpkg, apt, toolchain, etc.) were able to cope with non-Linux ports, and keep
that odd-but-why-not goal around, and evidently-enough achievable. In return,
the kFreeBSD port managed to show that it was actually releasable, at least
as a technological preview, thus making an example. In the daily work, we
have sometimes worked hand in hand. The recent porting efforts of the Debian
Installer happened roughly at the same time. When fixing some piece of code
for one, the switch-case would be left for the other. When some code could
be reused by the other, a mail would be sent to advise doing so, etc. In the
packaging effort, it also made a lot of difference that a non-Linux port is
exposed as released architecture: people attempted by themselves to fix code
that is Linuxish for no real reason.
The presence of the kFreeBSD is however also sometimes a difficulty for the
Hurd: in the discussions, it sometimes tends to become a target to be reached,
even if the systems are not really comparable. I do not need to detail the long
history of the FreeBSD kernel and the amount of people hacking on it, some of
them full-time, while the Hurd has only a small handful of free-time hackers.
The FreeBSD kernel stability has already seen long-term polishing, and a
fair amount of the Debian software was actually already ported to the FreeBSD
kernel, thanks to the big existing pure-FreeBSD hackerbase. These do not hold
for the GNU/Hurd port, so the expectations should go along.
Raphael: You re also very much involved in the
Debian Accessibility team. What
are the responsibilities of this team and what are you doing
there?
Samuel: As you would expect it, the Debian Accessibility team works on packaging
accessibility-related packages, and helping users with them; I thus do both. But
the goal is way beyond just that. Actual accessibility requires integration.
Ideally enough, a blind user should be able to just come to a Debian desktop
system, plug his braille device, or press a shortcut to enable speech synthesis,
and just use the damn computer, without having to ask the administrator to
install some oddly-named package and whatnot. Just like any sighted user
would do. He should be able to diagnose why his system does not boot, and at
worse be able to reinstall his computer all by himself (typically at 2am ).
And that is hard to achieve, because it means discussing about integration
by default of accessibility features. For instance, the Debian CD
images now beep during at the boot menu. That is a precious feature that
has been discussed between debian-boot and debian-accessibility
for a few weeks before agreeing on how to do it without too much disturbance.
Similarly, my proposition of installing the desktop accessibility engines
has been discussed for some time before being commited. What was however
surprisingly great is that when somebody brought the topic back for discussion,
non-debian-accessibility people answered themselves. This is reassuring,
because it means things can be done durably in Debian.
On the installation side, our current status is that the stable Debian
installer has a high contrast color theme, and several years ago, I have pushed
toward making standard CD images automatically detect braille devices, which
permits standalone installation. I have added to the Wheezy installer some
software speech synthesis (which again brought discussion about size increase vs
versatility etc.) for blind people who do not have a braille device.
I find it interesting to work on such topic in Debian rather than another
distribution, because Debian is an upstream for a lot of distributions.
Hopefully they just inherit our accessibility work. It at least worked for the
text installer of Ubuntu.
Of course, the Accessibility team is looking for help, to maintain
our current packages, but also introduce new packages from the TODO list or create
some backports. One does not need to be an expert in accessibility: tools can
usually be tested, at least basically, by anybody, without particular hardware
(I do not own any, I contributed virtual ones to qemu). For new
developments and ideas, it is strongly recommended to come and discuss on
debian-accessibility, because it is easy to get on a wrong track that does not
bring actual accessibility.
We still have several goals to achieve: the closest one is to just fix the
transition to gnome3, which has been quite bad for accessibility so far :/
On the longer run, we should ideally reach the scenario I have detailed above:
desktop accessibility available and ready to be enabled easily by default.
Raphael: What s the biggest problem of Debian?
Samuel: Debian is famous for its heated debian-devel discussions. And some
people eventually say this no fun any more . That is exemplified in a less
extreme way in the debian-boot/accessibility discussions that I have mentioned
above. Sometimes, one needs to have a real stubborn thick head to continue
the discussion until finding a compromise that will be accepted for commit.
That is a problem because people do not necessarily have so much patience, and will
thus prefer to contribute to a project with easier acceptance. But it is also
a quality: as I explained above, once it is there, it is apparently for good.
The Ubuntu support of accessibility in its installer has been very diverse, in
part due to quite changing codebase. The Debian Installer codebase is more in a
convergence process. Its base will have almost not changed between squeeze and
wheezy. That allowed the Debian Accessibility team to continue improving its
accessibility support, and not have to re-do it. A wiki page explains how to
test its accessibility features, and some non-debian-accessibility people do go
through it.
A problem I am much more frightened by is the manpower in some core teams. The
Debian Installer, grub, glibc, Xorg, gcc, mozilla derivatives, When reading
the changelogs of these, we essentially keep seeing the same very few names over
and over. And when one core developer leaves, it is very often still the same
names which appear again to do the work. It is hard to believe that there are
a thousand DDs working on Debian. I fear that Debian does not manage to get
people to work on core things. I often hear people saying that they do not even
dare thinking about putting their hands inside Xorg, for instance. Xorg is
complex, but it seems to me that it tends to be overrated, and a lot of people
could actually help there, as well as all the teams mentioned above. And if nobody
does it, who will?
Raphael: Do you have wishes for Debian Wheezy?
Samuel: That is an easy one Of course I wish that we manage to release the
hurd-i386 port. I also wish that accessibility of gnome3 gets fixed enough
to become usable again. The current state is worrying: so much has changed
that the transition will be difficult for users already, the current bugs will
clearly not help. I also hope to find the time to fix the qt-at-spi bridge,
which should (at last!) bring complete KDE accessibility.
Raphael: Is there someone in Debian that you admire for their
contributions?
Samuel: Given the concerns I expressed above, I admire all the people who do
spend time on core packages, even when that is really not fun everyday. Just
to alphabetically name a few people I have seen so often here and there in the
areas I have touched in the last few years: Aur lien Jarno, Bastian
Blank, Christian Perrier, Colin Watson, Cyril Brulebois, Frans Pop, J rg
Jaspert, Joey Hess, Josselin Mouette, Julien Cristau, Matthias Klose, Mike
Hommey, Otavio Salvador, Petr Salinger, Robert Millan, Steve Langasek. Man, so
many things that each of them works on! Of course this list is biased towards the parts that I touched, but people working in others core areas also deserve the same admiration.
Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook.
3 comments Liked this article? Click here. My blog is Flattr-enabled.
experimental
, I got myself into other areas.
Debugging gzip
Jakup Wilk noticed
a while ago that some multiarchified packages couldn t be co-installed
due to gzipped files being different between architectures. That was
reported as #647522 against the
gzip
package.
While some developers consider the lack of determinism (as in: it s
not in the gzip specification, and the current implementation
generates different packages anyway!) as a dead-end for the multiarch
experiment, it didn t look like undebuggable or unfixable. And indeed,
as confirmed by a
quick
analysis:
a lack of clean-up when several files are processed at once can lead
to different results, depending on the order in which files are specified
on the command line; the patch for that is trivial, and was later
made smaller
and the need for it was
explained.
Working in the Release Team
I reviewed/approved a few packages for squeeze
, but also took care
of handling or finishing a few transitions (as seen in my
hints file), among
which the funny iceweasel9
/libmozjs
ones; release tools are nice,
but one gets to learn lots of stuff at once (which isn t a negative
aspect). I hacked a tiny
collision detector
so that packages involved in several transitions can be easily
spotted. Given the huge number of ongoing transitions we had lately,
that didn t look overkill.
Squashing bugs
It had been a very long time since my last working on totally random
RC bugs. The Bug Squashing Party organized at
IRILL was a very nice opportunity to get back
to totally crazy bugs in unknown packages, but also to meet with other
Debian contributors; sponsoring maintainers with good patches on their
first try was nice, but walking other contributors through their first
patches sent to the BTS or through their first NMUs was nice too.
Waving good bye to yada
Back in the M rida QA meeting I attended in 2007, there were already
jokes about how bad yada was, and how it should die in a fire
etc. When I started looking at the RC bug list, I quickly switched to
scrolling it backwards, and I wondered how much work was left. The
details can be seen in #660548, and
the result is:
yada is gone!
sanity++;
packages.debian.org
Both long descriptions and translations for packages in some suites
disappeared after the
switch to Description-md5
. Thanks
to a quick and reduced packages.debian.org
setup (mostly: en
+de
for squeeze
+sid
+experimental
), I managed to find my way through
Perl and DB files to propose patches for
#657557. I m still waiting for a
confirmation, but in case it works fine, we could even get a fix for
DDTP/DDTSS.
dpkg --get-selections
, dpkg --list
, maybe other commands).
multiarch allows you to install packages from different architectures on the same machine. This can be useful if your computer can run programs from 2 architectures (eg. x86 CPU supporting i386 and amd64), or if you often need to cross-compile software and thus need the libraries of your target architecture.
Test dpkg with multiarch support
If you want to test multiarch support in dpkg, install the package from experimental (apt-get install dpkg/experimental
assuming you have experimental in your sources.list).
Then you can add a supplementary architecture to your system by doing sudo dpkg --add-architecture <arch>
(e.g. i386 if you are on amd64, and vice-versa). APT will automatically pick up the new architecture and start downloading the Packages file for the new architecture (it uses dpkg --print-foreign-architectures
to know about them).
From there on you can install packages from the foreign architectures with apt-get install foo:<arch>
. Many packages will not be installable because some of their dependencies have not yet been updated to work with in a multiarch world (libraries must be installed in a multiarch-compliant path so as to be co-installable, and then marked Multi-Arch: same
). Other dependencies might need to be marked Multi-Arch: foreign
. See wiki.debian.org/Multiarch/Implementation for more HOWTO-like explanations.
Now is a good time to see if you can install the foreign packages that you could need in such a setup and to help to convert the required libraries.
You can also read Cyril Brulebois article which quickly shows how to hunt for the problematic packages which have not been converted to multiarch (in his sample, ucf is not ready. Since it s an Architecture: all
package which can run on any architecture, it means that it s lacking a Multi-Arch: foreign
field).
Report bugs
If you discover any bug in dpkg s multiarch implementation, please report it to the Bug Tracking System (against dpkg with the version 1.16.2~wipmultiarch ).
If you notice important libraries or packages which are not yet multiarch ready, please open wishlist bug reports requesting the conversion and point the maintainers towards the wiki page linked above. Even better, prepare patches and submit those with your bug reports.
Again, you can follow the lead of Cyril Brulebois who filed 6 bugs!
Review the multiarch implementation
If you re a C programmer and have some good knowledge of dpkg (or are willing to learn more of it), we would certainly benefit from more eyes reviewing the multiarch branch. If you want to discuss some design issues of the multiarch implementation in dpkg (or have questions related to your review), please get in touch via debian-dpkg@lists.debian.org.
The latest version of the branch is pu/multiarch/master in Guillem s personal repository. I have my own version of the branch (pu/multiarch/full) which is usually a snapshot of Guillem s branch with my own submitted fixes.
$ git clone git://git.debian.org/dpkg/dpkg.git $ cd dpkg $ git remote add guillem git://git.hadrons.org/git/debian/dpkg/dpkg.git $ git remote add buxy git://git.debian.org/~hertzog/dpkg.git $ git fetch guillem && git fetch buxyIf you followed the instructions above, the relevant branches are thus guillem/pu/multiarch/master and buxy/pu/multiarch/full. Both branches are regularly rebased on top of master where Guillem merges progressively the commits from the multi-arch branch as his review progresses. Thank you in advance for your help bringing multiarch in shape for Debian Wheezy,
6 comments Liked this article? Click here. My blog is Flattr-enabled.
dpkg
was uploaded to experimental
a few times lately, let s sum it
up quickly:
dpkg
upload to experimental
finally happened. One shall note the prominent This is a WIP
release, command line interfaces will change. notice.grep-aptavail -F Multi-Arch $i -sPackage
(with
$i
being same
or foreign
), I found some bugs:
5 comments Liked this article? Click here. My blog is Flattr-enabled.
dpkg
from experimental
, add
a foreign architecture, and start trying to install packages. Example
on amd64
:
# dpkg --add-architecture i386
# dpkg --print-foreign-architectures
i386
# apt-get update
[ lots of amd64 and i386 Packages files get downloaded ]
# apt-get install mksh:i386
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
ed:i386
The following NEW packages will be installed:
mksh:i386
0 upgraded, 1 newly installed, 0 to remove and 9 not upgraded.
Need to get 414 kB of archives.
After this operation, 707 kB of additional disk space will be used.
Get:1 http://ftp.fr.debian.org/debian/ sid/main mksh i386 40.4-2 [414 kB]
Fetched 414 kB in 0s (664 kB/s)
Selecting previously unselected package mksh.
(Reading database ... 171933 files and directories currently installed.)
Unpacking mksh (from .../archives/mksh_40.4-2_i386.deb) ...
Processing triggers for menu ...
Processing triggers for man-db ...
Setting up mksh (40.4-2) ...
update-alternatives: using /bin/mksh to provide /bin/ksh (ksh) in auto mode.
Processing triggers for menu ...
# mksh
$ ldd $(which mksh)
linux-gate.so.1 => (0xf779c000)
libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xf75d6000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf75b9000)
/lib/ld-linux.so.2 (0xf779d000)
Of course, installing an i386
mksh
package isn t exactly what
multiarch is about. Dozens of packages have been patched already to
add Multi-Arch
fields, but until their (recursive) dependencies have
been multiarch-ified, foreign packages can be uninstallable, as can be
seen below, with the usual why is it uninstallable? hunt (shortened
output):
# apt-get install psutils:i386
The following packages have unmet dependencies:
psutils:i386 : Depends: libpaper1:i386 but it is not going to be installed
# apt-get install libpaper1:i386
The following packages have unmet dependencies:
libpaper1:i386 : Depends: ucf:i386 (>= 0.28) but it is not installable
Recommends: libpaper-utils:i386 but it is not going to be installed
# apt-get install ucf:i386
E: Package 'ucf:i386' has no installation candidate
Another example, successful handling of the installation of a foreign
package, while it s already installed with the host architecture:
# apt-get install xz-utils:i386
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
liblzma5:i386
Suggested packages:
xz-lzma:i386
The following packages will be REMOVED:
xz-utils
The following NEW packages will be installed:
liblzma5:i386 xz-utils:i386
0 upgraded, 2 newly installed, 1 to remove and 9 not upgraded.
Need to get 440 kB of archives.
After this operation, 410 kB of additional disk space will be used.
Do you want to continue [Y/n]?
Get:1 http://ftp.fr.debian.org/debian/ sid/main liblzma5 i386 5.1.1alpha+20110809-3 [205 kB]
Get:2 http://ftp.fr.debian.org/debian/ sid/main xz-utils i386 5.1.1alpha+20110809-3 [235 kB]
Fetched 440 kB in 0s (478 kB/s)
dpkg: xz-utils: dependency problems, but removing anyway as you requested:
dpkg depends on xz-utils.
xz-lzma depends on xz-utils.
dpkg-dev depends on xz-utils.
(Reading database ... 171952 files and directories currently installed.)
Removing xz-utils ...
Processing triggers for man-db ...
Selecting previously unselected package liblzma5:i386.
(Reading database ... 171908 files and directories currently installed.)
Unpacking liblzma5:i386 (from .../liblzma5_5.1.1alpha+20110809-3_i386.deb) ...
Selecting previously unselected package xz-utils.
Unpacking xz-utils (from .../xz-utils_5.1.1alpha+20110809-3_i386.deb) ...
Processing triggers for man-db ...
Setting up liblzma5:i386 (5.1.1alpha+20110809-3) ...
Setting up xz-utils (5.1.1alpha+20110809-3) ...
# dpkg -l xz-utils xz-utils:i386 'liblzma*:*'
[ ]
un xz-utils <none>
ii xz-utils 5.1.1alpha+20110809-3
ii liblzma5:amd64 5.1.1alpha+20110809-3
ii liblzma5:i386 5.1.1alpha+20110809-3
# ldd $(which xz)
linux-gate.so.1 => (0xf776b000)
liblzma.so.5 => /usr/lib/i386-linux-gnu/liblzma.so.5 (0xf7724000)
librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xf771b000)
libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xf7701000)
libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xf75a4000)
/lib/ld-linux.so.2 (0xf776c000)
# zgrep -a '_("Activities")' gnome-shell-3.2.2.1.tar.xz
this._label = new St.Label( text: _("Activities") );
zgrep
is a shell script, but it calls xz
, which is from the i386
package, and everything runs just fine. Running it through strace -f
-e ''
, I discovered those messages, which I had never seen before:
[ Process PID=8900 runs in 32 bit mode. ]
[ Process PID=8899 runs in 64 bit mode. ]
[ Process PID=8900 runs in 32 bit mode. ]
[ Process PID=8899 runs in 64 bit mode. ]
What s next?
We re late! It s time to check what happens with that dpkg
package, report bugs, and convert more libraries! Please think of the
kittens, and coordinate with the release team to make sure you
don t delay a transition when uploading a shiny, multiarch-ified
package. In a nutshell, if you received a patch from Steve Langasek or
Riku Voipio, it s a good indication your package will be helpful
quickly when it s multiarchified.
Since zlib
is directly depended on by 2000+ packages,
#569697 was pinged right after the
dpkg
upload; but many other packages will need patches and heavy
testing.
Hurry up, the freeze is coming, we need to shake it up as soon as
possible!
Proving [ ] that a team was the best way to maintain large package sets changed the way people work on Debian.Raphael: You re one of the most active contributors of the team which is packaging GNOME for Debian. What would you suggest to a new contributor who would like to help the team? Josselin: There are several ways to contact the team, but the recommended one has always been IRC. We hang on #debian-gnome on the OFTC network, so just come around and ask for us. The real question is what you want to do in the team. Of course, most new volunteers want to help packaging the latest and greatest version of GNOME into unstable as soon as possible, but unless they already have Debian background, this is not the easiest task. Since there are already people working on this, the big packages are usually waiting on dependencies. I used to direct newcomers towards bug triage, but it is a tedious task and I m now convinced that our huge bug backlog will never be dealt with. The most useful thing to do for newcomers now is probably to find a GNOME or GNOME-related package that needs improvement or is lagging behind, and simply try to work on it. You can also come and fix the bugs you find annoying. Find a patch on the GNOME bugzilla, or cook it yourself, propose it, and if it s worthy enough you ll soon get commit access.
Our huge bug backlog will never be dealt with.At this point I feel worth mentioning that if no one answers in 10 minutes, it doesn t mean that no one will answer in 2 hours, so please stay on the channel after asking. Raphael: There s been some controversy about GNOME 3 and the direction that the project is taking. What s your personal stance on GNOME 3? And what s the position of the pkg-gnome team? Josselin: The controversy is not new to GNOME 3, but the large-scale changes made with it have put it more prominently. The criticism usually boils down to a few categories:
On the whole we don t intend to diverge from the upstream design, on which a lot of good work has been done.Point 3 is more complex. Red Hat being the company spending the most on GNOME, it is obvious that their employees work on making things work for their distribution. An example is the recurring discussions about relying on system services that are currently only implemented by systemd. Since there is a lot of (mostly unjustified) resistance against systemd in Debian, and since it won t work on kFreeBSD anyway, someone needs to develop an alternative implementation of these services for upstart and sysvinit. Everything is in place for someone else to do the job but it has to be done, and this can be frustrating. Especially since it can also be hard to integrate changes needed for other distributions . Hardware requirements are mostly a consequence of the previous criticism: there s hardware that most distributions just don t want to bother supporting. We ve seen it in squeeze with the introduction of a hard dependency on PulseAudio. The Debian GNOME team (together with the Gentoo maintainers) made this dependency optional, carrying heavy patches, in order to cover the cases where it does not work. Now that it has gained more maturity, making this effort obsolete, the new tendency is to require 3D acceleration. For various reasons, it is not available to everyone . On this matter, the position of the Debian GNOME team has always been to support as much different configurations as possible with reasonable effort. Thanks to efforts from the incredible Vincent Untz, upstream supports a so-called fallback mode , which is the GNOME panel from 2.x with a lot of its bugs fixed. We intend to support this mode for as long as reasonably possible in Debian, possibly even after upstream ends up dropping it. However, other applications are going to require 3D because GStreamer is moving to clutter too, affecting video playback performance on non-accelerated systems . For epiphany this is not a problem; only embedded video will be affected. But for totem, this is a major issue; because of that we will probably keep totem 3.0 in wheezy. Finally, there is a natural human tendency to dislike change (I have it too), and it applies a lot to desktop users habits. Needless to say a change of such a scale as introducing GNOME Shell can trigger reactions. However, I don t think it is reasonable, because of this resistance, to keep gnome-panel 2.x in Debian. This would be a lot of work on obsolete technology, and would prevent the upcoming removal of a lot of deprecated libraries. This time is much better spent improving gnome-panel 3.x in Debian and keeping the fallback mode great. One of the change that was made in Debian was to make it easier to find, being available as GNOME Classic directly from the login manager, instead of having to find it in an obscure configuration panel. In all cases, I would recommend to actually try GNOME Shell for a few hours before ditching it. I had never been accustomed to a new environment as quickly ever before.
In all cases, I would recommend to actually try GNOME Shell for a few hours before ditching it.Having seen several of my GDM patches reverted without a warning, I know we are not finished with carrying patches in Debian packages.
3 years [of support] is really not enough for corporate users.Long-term support will not magically fix all problems in Debian, but it will bring more corporate users into the picture. And with corporate users come paid Debian developers, who can work on critical pieces of the system. Debian was built on the synergy between individuals and companies, and in recent years perhaps as a reaction against what happened with Ubuntu we ve kind of forgot the latter. A lot of individuals have joined the project, and they are actively working, for example, on shortening the release cycle, which goes against the interest of professionals. We should embrace again such users and developers, and that means adapting to the current needs of larger entities. Raphael: You re the maintainer of python-support, a packaging helper that was competing with python-central. Both helpers are now deprecated in favor of dh_python2. Does this mean that the situation of Python in Debian is now sane? Or are there remaining problems? Josselin: dh_python2 (and the Python3 version, dh_python3) has a sane enough design. It fixes a lot of issues in python-central and also python-support, at the expense of somehow reduced functionality for developers. However, just like the previous tools, it merely works around design mistakes in the Python interpreter. For example it is not possible to split binary modules, pure-Python modules and byte-compiled modules in different directory trees, like Perl does although PEP 3147 introduces a way to do so. There is still no sane and standardized way to deal with module versions. There is no difference made between the module (which is a part of language semantics) and the file containing it (an information which depends on the implementation). Developers heavily rely on introspection features and make assumptions based on the implementation, that make it impossible to work around problems with module files. Such problems are not restricted to Python. Those who fought against Ruby gems could tell even worse stories. While introducing GObject introspection packages in Debian (they can be used in JavaScript and Python to provide modules based on GObject libraries), I was pleased to see a clear distinction between file and module, but I was again struck by the fact you are not forced to declare API versions in your Python/JS code. In all cases, there is no reliable way to detect runtime dependencies in a given Python or JavaScript file, which leaves the maintainer to declare them by hand, and of course, often be wrong about them. Add to that the fact that most errors cannot be detected before runtime. For all these reasons, and while still being fond of Python for scripts and prototyping, I ve become really skeptical of using purely interpreted languages to write real applications. Some GNOME developers are moving away from Python and JavaScript, mostly towards Vala; I can only approve of that move and hope the same happens to other projects. Raphael: Is there someone in Debian that you admire for their contributions? Of course there is the never-sleeping, never-stopping, Michael Biebl who can upload a whole GNOME release in a single week-end. But there are a lot of awesome people who make Debian something that simply works. I could talk about Cyril Brulebois from the X strike force, Julien Cristau from the release team, Sjoerd Simons for his sound advice and work on plumbing, Luca Falavigna who is so fast at processing NEW, to quote only a few of those I work with frequently. And of course, Jordi and Sam for their humor.
Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook .
8 comments Liked this article? Click here. My blog is Flattr-enabled.
master
during this
merge window. Which is
what happened,
a few days before Christmas.
The other components involved in XI2.2
(aka. multitouch ) were
packaged in experimental
while the server side was getting prepared:
Given we reached the
1.12 RC1
stage, it s a good idea to start building drivers against the new
server to make it possible for users to perform some tests. And as
usual, a new server means bumped input and video ABI, meaning a
rebuild for the drivers to pick new dependencies. Some of them also
needed a few fixes to make them build against the new server. Nothing
that can t be fixed with a few merges from upstream master
branches.
The usual set of major drivers was uploaded to experimental
:
xserver-xorg-input-evdev
xserver-xorg-input-keyboard
xserver-xorg-input-mouse
xserver-xorg-input-synaptics
xserver-xorg-input-void
xserver-xorg-video-ati
xserver-xorg-video-dummy
xserver-xorg-video-nouveau
xserver-xorg-video-fbdev
xserver-xorg-video-intel
xserver-xorg-video-vesa
master
branch was created, and packaged
with SNA support enabled. SandyBridge's
New Acceleration has apparently reached a point where it can be
published to the masses, so here we go. Some details about it can be
found in the
initial commit.
Also, for those wondering about the xorg-server
FTBFS
on some
architectures,
fixes are pending.
Happy new year.
synaptics
input driver, between the
1.4.1 and the 1.5.0 release, as reported in Debian
#649002 by many users. Basically, no
more touchpad on PowerPC (hi, iBook G4 users!). :-(
What follows is how I tracked it down. The upstream bug report is
fdo#43728. Anyone could have
done so, there s no black magic involved. A little hint maybe: git bisect
is really easy on X drivers, since one can build and test
without the Debian packaging bits.
1st step: Getting started
You need sources and build dependencies, nothing fancy. Since packages
might be named a bit differently, there s a reference to the relevant
upstream repositories in debian/watch for X packages.
# You need git here:
debcheckout xserver-xorg-input-synaptics synaptics.git
cd synaptics.git
# Let s get the upstream tags and branches:
cat debian/watch
git remote add upstream git://anongit.freedesktop.org/xorg/driver/xf86-input-synaptics
git fetch --all
# Let s install build dependencies:
sudo apt-get build-dep xserver-xorg-input-synaptics
2nd step: Reproducing
It was said 1.5.0 was the first known buggy version, so let s make
sure:
# Get the appropriate tag:
git checkout xf86-input-synaptics-1.5.0
# Prepare the build system:
autoreconf -vfi
# X finds its modules under /usr, not /usr/local:
./configure --prefix=/usr
# Build and install:
make && sudo make install
Now time to restart the display manager, and confirm that the pointer
is not moving bug reproduced.
Now let s check the 1.4.1 release isn t affected:
# Clean everything:
git clean -xdf
git checkout xf86-input-synaptics-1.4.1
autoreconf -vfi
./configure --prefix=/usr
make && sudo make install
And after a display manager restart, the pointer is moving again,
good! For reference, the log has very different lines about
appletouch
, so it can be used to programmatically learn about the
status (good or bad).
3rd step: Narrowing it down
So, we have a known good version and a known bad version. Time for a
binary search to find the guilty commit which introduced that
regression!
git bisect start
git bisect good xf86-input-synaptics-1.4.1
git bisect bad xf86-input-synaptics-1.5.0
You don t even need to know that 1.4.x and 1.5.x live in different
branches, git figures that out for you:
Bisecting: a merge base must be tested
[de0dfb76444ad4160468d00515876c91a9fa20bf] synaptics 1.4.0
It s just a matter of running autoreconf && ./configure && make && sudo make install && sudo /etc/init.d/xdm restart
every step of the way, so it s pretty easy.
No wonder, 1.4.0 was working OK, so it can be recorded as such through
git bisect good
, and the binary search goes between that commit and
1.5.0. After a few iterations of git bisect good
and git bisect bad
,
we get to the commit reported on the upstream bug.
As an extra bonus, mentioning the upstream bug number/URL in the
Debian bug means it can be marked as forwarded
there and we ll
receive automatic notifications when its status changes, thanks to
bts-link.
Now, if you want to provide a patch for this bug, you may want to try
and revert this commit.
4th step: Providing a patch
Let s go back to the affected release and try to revert the guilty
commit:
git checkout xf86-input-synaptics-1.5.0
git revert 13543b156d78bc4d01a19844a5ee8f283269621b
Unfortunately, some later commits modified the affected areas so we re
running into conflicts:
error: could not revert 13543b1... eventcomm: replace synaptics-custom TEST_BIT with server's BitIsOn.
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
Let s try to understand what the
offending commit
did: it replaced a set of macros with a single one, taken from the
server. Both the old TEST_BIT()
and the new BitIsOn()
take 2
arguments, but the order is reversed. Reverting it should only be a
matter of introducing the TEST_BIT()
macro again (along with the two
other ones it needs), and using it.
The problem is replacing all BitIsOn(foo,bar)
with
TEST_BIT(bar,foo)
: foo
and bar
might not be trivial, they could
be complex C expressions, and a replacement in your favourite editor
might not get all occurrences right.
Thankfully, there s a nice tool to handle such things, called
coccinelle. I won t go into details,
just show how it can help here. Basically you just need to craft a
tiny patch, called a semantic patch, which describes what I wrote in
the previous paragraph. You only need to declare two expressions, say
a
and b
, and declare that all BitIsOn(a,b)
must be replaced with
TEST_BIT(b,a)
. Here s the syntax:
@@
expression a,b;
@@
-BitIsOn(a,b)
+TEST_BIT(b,a)
Save it under testbit.cocci
and apply it through spatch
(from the
coccinelle
package), asking it to perform in-place replacement
(we re in a git checkout copy, remember):
# Apply:
spatch -sp_file testbit.cocci -in_place .
# Profit:
git diff
Then you can run git commit -s
, write a nice commit message, send it
upstream, and enjoy the rest of the night.
Coming soon to a mirror near you:
fixing commit.
As mentioned on the upstream bug report, I got the Debian reference
wrong in the commit message, I really meant
#649002.
unstable
on Intel hardware, this post is for you.
Some
buffer freeing code
was added in libdrm
2.4.28 to try and fix exhaustion of per-process
limits. Some safeguards (assert()
) were put in place to see whether
some other components needed fixing (like unbalanced
map()
/unmap()
). It s hard to miss those, since the server crashes
when something s wrong. Good news: for affected users, downgrading to
libdrm 2.4.27 (currently available in testing
) should restore a
functional setup.
So far, patches have floated around for
libva
[1],
xserver-xorg-video-intel
[1,2]
and libdrm
[1,2,3]
itself. Since libdrm
has already been exposed to a wide audience for
a while, a new upstream release is planned in a few days, disabling
those assert()
s. Other packages will then have some extra time to
get new releases with the appropriate patches.
1.10
to 1.11
. That means X drivers (for input and video) need to
be rebuilt against the new server, which is happening through
binNMUs. That also means the X stack from sid
might be uninstallable
for a few hours, but impatient people can still use the stack from
wheezy
in the meanwhile.
Please refrain from reporting uninstallability bugs. That s expected,
can t be avoided, and only for a few hours (assuming no driver starts
to Fail To Build From Source).
Many thanks to the following people, who joined the let s do a
pre-upload crash test effort:
squeeze-backports
a shot, and cross fingers!
As usual, x.debian.net contains the relevant
documentation. Hopefully, the short
squeeze-backports
instructions
will be sufficient. If you encounter some issues, feel free to contact
debian-x@
.
kfreebsd-*
build daemons from me some time ago, but still:
smile of the day.
Thanks, Russ.
/dev/videoX
to the network, and done.
Example:
# Streaming:
cvlc v4l2:///dev/video0 --no-audio --sout "#transcode vcodec=mp2v,vb=3072 :std access=udp,mux=ts,dst=224.0.0.1 "
# Playing, possibly on a remote machine:
vlc udp://@224.0.0.1:1234
Notes:
v4l2
vs. v4l
depending on the distribution (sid
vs. squeeze
).v4l[2]://
part, one for the
device (/dev/video0
).uvcvideo
module, getting No space left on
device
when the second (c)vlc is started.--resolution
to request a specific
resolution (the device will fall back to another resolution if the
requested one is unavailable); --frames
to specify the number of
frames to capture (lower noise, but possibly higher blurriness).threading
module. To
avoid encountering the same bandwidth issue, a tiny lock ensures a
single fswebcam
instance runs at a time.videoX-timestamp.jpg
and to log rotate them after a while, for
further viewing/reviewing during a given time window.# Only keep a rectangle of width W, height H, starting at the point (X,Y):
convert -crop WxH+X+Y capture.jpg capture.jpg
# Include a timestamp on the top-left corner:
convert -box white -font Fixed -draw "text 2,12 \"$timestamp\"" capture.jpg capture.jpg
videoX-current.jpg
symlink for each /dev/videoX
device is trivial.ssh
ing from another machine is the ideal
situation. But that requires an extra machine, which might not be
available during a train trip.:)
Alternative, viable solution 2:
While I m by no means a phone addict, I tend to have it with me more
or less all the time, and it can be connected through a mini-B USB
cable. Oh, but then, maybe I could turn it into a suitable device as
described above?
That s a Motorola RAZR V3, it runs Java applications, and there s a
SDK available for Linux (32 bits) through the
Motorola developer network. That
might be enough, so I decided to jump through some hoops to see
whether that s indeed feasible. Not because I like it much better than
the Arduino-based solution, just because I can.
My hack orola page explains how I
went from the maybe it s possible idea to the yes, now I know
how to build, upload, and run a custom application certitude. It
still lacks the actual Java code running on the phone, as well as its
Unix daemon counterpart, but for a good reason: they need be written!
At the moment the following sections are available:
Next.